|
|
|
|
|
|
|
scenario could be named Deposit Funds to a Particular Active Account by Account Number. The steps for this scenario might be |
|
|
|
|
|
|
|
|
2. Enter amount of deposit. |
|
|
|
|
|
|
|
|
3. Persist the transaction by clicking the Store button. |
|
|
|
|
|
|
|
|
4. Complete the transaction by clicking the Done button. |
|
|
|
|
|
|
|
|
Figure 11.3.
The actual
frmAccountMaintForm
form, as seen in
Visual Basic. |
|
|
|
|
|
|
|
|
Ideally, you might try to create such scenario scripts so that you have a guideline for the behavior and features of each form. This practice of scripting your forms also encourages reuse of forms by not only other team members but also other teams. |
|
|
|
|
|
|
|
|
Understanding the Encapsulation of Data Presentation into a Separate Class |
|
|
|
|
|
|
|
|
Attempting to map fields on a form to properties in a class can be tedious. The most pressing concern is to avoid breaking the rule of encapsulation. That is, in theory, the only object that should access the values of a business or domain class is the class itself. Any other class that needs such information is probably not properly designed. |
|
|
|
|
|
|
|
|
The Graphical User Interface Subsystem Object Model |
|
|
|
|
|
|
|
|
You can use the diagram in Figure 11.1 to design the mechanism for effectively modeling the interactions between forms and business classes. Because the form is, in a sense, a class, you can model it as a class in your model. Indeed, a form can have methods, attributes, and events just like classes. In the specification for your form class in Visual Modeler, make sure to mention that the class represents a form. Figure 11.4 gives you an example of the specification window for the frmAccountMaintForm form. |
|
|
|
|
|
